Each year there is an increase in the amount of computer automation for the home and office. Typically, such increases occur in discrete software applications that are specific to a desired goal or objective. For example, there are individual applications for billing, payroll, word processing, time keeping, inventory tracking, and personal organization. Each of these applications can be implemented and distributed by a different vendor and loaded onto a single computer.
User applications typically share compatibility and operability with an operating system that controls the computer. Typical examples of operating systems are Windows 95™, Windows 98™, Windows 2000™, and Windows NT™ available from Microsoft Corp., Linux™ available from Red Hat, OS/2 available from IBM Corp., and the Apple Macintosh Operating system available from Apple Computer, Inc. Thus, each application installed onto the computer must be able to run on the operating platform supporting the computer.
Operating systems available today allow a user to have more than one application running (loaded or open) simultaneously. This is also called multi-processing. Before opening (or launching) an application, it is in an “unloaded” state, stored in permanent or long term storage/memory. When an application is “launched”, it becomes the “active” application. If another application is launched, a loaded and active application remains loaded but becomes “inactive”. Thus, multiple applications may be loaded and “running” at any one time. However, unless the computer has multiple processors (CPUs), only one application is actually “active” at a time.
One problem many users face when using a plurality of applications, windows, or data sets is that of switching between the various applications, windows, or data sets that are running simultaneously. For example, suppose a user is obtaining data about a patient from a practice management application in a doctor's office and wants to look at that patient's digitally stored x-ray images. The user must open or re-activate the x-ray image application, window, or data set; enter some search term that designates the patient; and wait for the application, window, or data set to return with the patient's x-ray images in the appropriate window. Thus, even though the user has the patient's identifying data in the practice management application that he/she is viewing, the user must open or activate the x-ray imaging application, and must then enter a query to locate and obtain the window containing the desired data. These additional operations can be time-consuming if the user is processing multiple patients per day.
The burden of having to manually enter data when the required data is available to the user in another window, application, or data set is compounded when certain applications, windows, or data sets require multiple pieces of data. For example, some applications, windows, or data sets require both a name and a social security number in order to distinguish between patients having the same name. In this example, the different social security numbers distinguish between the files of these two patients and their respective related information. Thus, even if a user is viewing a particular patient's profile in a patient management application and has the patient's social security number on screen, the user will still be required to type in the social security number, in addition to the patient's name, in the other desired application such as an x-ray imaging application. Some Windows™ programs allow a user to “cut-and-paste” information from one window to another. However, this method is time consuming when several fields of data need to be re-entered.
There is also a need to open a plurality of files across a plurality of applications, windows, or data sets in a network environment. In such a network environment, a first user could open one window in one application where that one window contains data useful to a plurality of other users on the network. It is desirable for the other users to access that data from the one window in the one application and use it to open other windows in other applications, instead of being forced to click on a plurality of boxes and/or type in the needed key data to open a file.
In addition, in either a single PC operation or a network operation, there is a need for a user to integrate a new application, window, or data set with existing applications, windows, or data sets. In this manner, it would be desirable for a user to purchase a new application and integrate the data residing in files in an existing application, window, or data set to create new files in the new application, window, or data set.
U.S. Pat. No. 6,711,564, issued to Crucs on Mar. 23, 2004, is incorporated herein by reference in its entirety. U.S. Pat. No. 6,711,564 describes a method and system for extracting data that is associated with one application, window, or data set and bridging that data to another application, window, or data set. The particular data form (application, window, or data set) is located using search criteria derived from a first active data form (application, window, or data set). If the particular data form is located in an unloaded (not running) application, window, or data set the requisite data form (e.g., application, window, or data set) is launched and made active. The necessary data is provided to the application, window, or data set to retrieve the particular window or data set of the data form. If the particular data form is located in a loaded application, window, or data set, the necessary data from the first data form is bridged into the loaded application, window, or data set. The necessary data to be bridged pre-exists in the form of text data within the application and is known by the operating system.
The system and method of U.S. Pat. No. 6,711,564 allows data to be extracted from the title bar or text associated with a window in another application. On many operating systems, a window (whether a main application window, title bar, or control) is defined by both its content and an operating system identifier (e.g., a class name). Using the window content and/or identifier, the system is able to search through a list of windows currently existing in an operating system (including child windows) for windows matching the desired criteria. Once the desired window is located, the relevant data can be extracted and used in the new application.
One disadvantage of the system and method of U.S. Pat. No. 6,711,564 is that, if a target window is a custom drawn window (e.g., a custom graphic window), the text data associated with that target window may be different from the information actually displayed in the custom drawn window. That is, each window class can have its drawing capabilities overridden by the underlying control class written by a company/developer in order to permit custom drawing of the window. With such styles, the window text data associated with the window in the operating system may not necessarily reflect the information displayed in the actual target window. Therefore, the desired information does not exist as data that can be extracted by the system and method of U.S. Pat. No. 6,711,564.
It is desirable to be able to bridge information between applications, windows, or data sets, even though the information may only initially exist as an image such as a custom graphic drawing.
Further limitations and disadvantages of conventional, traditional, and proposed approaches will become apparent to one of skill in the art, through comparison of such systems and methods with the present invention as set forth in the remainder of the present application with reference to the drawings.